Method and system for implementing and managing an enterprise identity management for distributed security in a computer system

ABSTRACT

A method and system for facilitating the management of user identities includes an ownership component, a registration component, and a servicing component. When a user first desires to access a system using the present invention, the registration component verifies the user&#39;s ownership of the underlying account by asking a variety of questions. Thereafter, when a user desires to service his account, the user may be re-queried to determine if he is attempting to access the correct information. An authentication and access component provides the functionality to access a system of the present invention. An audit component can be configured to periodically monitor the various accounts to ensure a continued linking between users and accounts.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. Ser. No. 13/079,666, entitled“Method and System for Implementing and Managing an Enterprise IdentityManagement for Distributed Security in a Computer System,” filed Apr. 4,2011. The '666 application is a Continuation in Part of U.S. Ser. No.12/692,817, entitled “Method and System for Implementing and Managing anEnterprise Identity Management for Distributed Security in a ComputerSystem,” filed Jan. 25, 2010. The '817 application is a Continuation ofU.S. Pat. No. 7,660,795 issued on Feb. 9, 2010 (aka U.S. Ser. No.10/716,251 entitled “Method and System for Implementing and Managing anEnterprise Identity Management for Distributed Security in a ComputerSystem” filed on Nov. 17, 2003). The '795 patent is aContinuation-in-Part of U.S. Pat. No. 7,143,095 issued on Nov. 28, 2006(aka U.S. Ser. No. 10/334,271 “Method And System For Implementing AndManaging An Enterprise Identity Management For Distributed Security,”filed on Dec. 31, 2002). The entire contents of all of theseapplications are hereby incorporated by reference.

FIELD OF INVENTION

This application generally relates to computer systems, and moreparticularly, to a method and system for managing user identities in acomputer system.

BACKGROUND OF THE INVENTION

Computer systems have evolved to the point where it is possible for auser to remotely access personal information via a computer. Forexample, one can monitor account balances, purchase securities, purchasegoods, check the status of goods, and the like, through the use of apersonal computer by using, for example, a web browser connected to theInternet.

In providing services such as those listed above, it is desirable thatcertain types of information be accessible only by authorized users. Forexample, only the account holder should be able to access informationregarding his bank account, be able to perform certain activities (e.g.,transfers and withdrawals) on said bank account, or be able to purchasegoods using funds from said bank account.

In the past, such security has typically been provided in the form ofthe combination of a user id and a password. For example, an account ata bank may be protected by having a user “log in” to a bankingapplication by providing a user id and password. However, such asecurity system may not provide as much security as desired. Forexample, if an unauthorized person were to become aware of the user idand password, the unauthorized person would then be able to accessinformation and perform tasks that should be limited to a select groupof authorized users.

There are several other problems with the above-described scenario. Theassociation between a user ID and an account may become broken. Forexample, a user named John Smith may select, as a user ID, JSMITH1 andan associated password for use with a bank account. Another person namedJoe Smith may select, as a user ID, JSMITH2 and an associated passwordfor use with a different account. After a few months of non-use, JoeSmith attempts to login to his brokerage account. Not remembering hisuser ID, he thinks his user ID is JSMITH1. After several unsuccessfullog-in attempts, he contacts a customer service representative.

In the prior art, the typical method of customer service verifying theuser would be to verify ownership of the account. After verifyingseveral pieces of information with Joe Smith (e.g., social securitynumber, mailing address, etc.), the customer service representative isconvinced that Joe Smith is who he says he is and grants him access tohis brokerage account using the name JSMITH1. When John Smith latertries to login, the same scenario may occur, as John Smith is no longerable to use the JSMITH1 name that he established and contacts customerservice to change the password. The result is that the JSMITH1 user IDbecomes associated with both the accounts of John Smith and Joe Smithand customer service needs to intervene in order to grant the userstheir desired authorization level.

Thus, no sufficient system exists that accurately associates customerrelationship and validates the continuing integrity of the customerrelationship. In particular, the prior art is solely concerned withverifying the ownership of the account, and not verifying therelationship between the user ID and the account. It is desirable tohave a more robust method of managing user identities in a computerizedsystem.

SUMMARY OF THE INVENTION

A system, method, and computer program product for managing identitiesis described. The method may comprise assigning a positive weight to afirst transaction initiated by an identity associated with an accountand from a location consistent with a location associated with aprevious transaction; assigning a negative weight to a secondtransaction initiated by the identity associated with the account andfrom a location inconsistent with the location associated with theprevious transaction; and determining a likelihood that the identityowns the account based upon the positive weight and the negative weight.

The method may further comprise assigning a positive weight to a firsttransaction initiated by an identity associated with an account and froma device consistent with a device associated with a previoustransaction; assigning a negative weight to a second transactioninitiated by the identity associated with the account and from a deviceinconsistent with the device associated with the previous transaction;and determining a likelihood that the identity owns the account basedupon the positive weight and the negative weight.

The method may further comprise assigning a positive weight to a firsttransaction initiated at a first time by an identity associated with anaccount; assigning a negative weight to a second transaction initiatedat a second time by the identity associated with the account; anddetermining a likelihood that the identity owns the account based uponthe positive weight and the negative weight.

The method may further comprise comparing a first transaction to asecond transaction; assigning one of a positive weight and a negativeweight to the comparison based upon the order in which the firsttransaction and the second transaction occur; and determining alikelihood that an identity owns an account associated with the firsttransaction and the second transaction based upon the positive ornegative weight.

The method may further comprise comparing a transaction to a pattern oftransactions; assigning one of a positive weight and a negative weightto the comparison; and determining a likelihood that an identity owns anaccount associated with the transaction based upon the positive weightor the negative weight.

The method may further comprise generating a pattern associated with agroup of transaction amounts indicative of a spending pattern; comparingthe pattern to a transaction amount; assigning one of a positive weightand a negative weight to the comparison; and determining a likelihoodthat an identity owns an account associated with the transaction basedupon the positive weight or the negative weight.

The method may further comprise generating a pattern associated with atleast one of: a group of withdrawals, inquiries, and deposits;comparing, by the computer-based system, the pattern to a transaction;assigning, one of a positive weight and a negative weight to thecomparison; and determining a likelihood that an identity owns anaccount associated with the transaction based upon the positive weightor the negative weight.

The method may further comprise assigning a positive weight to asuccessful transaction initiated by an identity associated with anaccount; assigning a negative weight to an unsuccessful transactioninitiated by the identity associated with the account; determining alikelihood that the identity owns the account based upon the positiveweight and the negative weight; and posing a question to a user at leastone of periodically and in response to assigning a negative weight to anunsuccessful transaction to verify that the user is the owner of theidentity.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived byreferring to the detailed description and claims when considered inconnection with the Figures, where like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 presents a block diagram overview of an embodiment;

FIG. 2 is a flowchart illustrating an exemplary process by which a usermay create a user ID; and

FIG. 3 shows a flowchart depicting an exemplary method for assigningpositive and negative weights to transactions.

DETAILED DESCRIPTION

The present disclosure may be described herein in terms of variousfunctional components and various processing steps. It should beappreciated that such functional components may be realized by a varietyof different hardware or structural components configured to perform thespecified functions. For purposes of illustration only, exemplaryembodiments of the present invention will be described herein. Further,it should be noted that, while various components may be suitablycoupled or connected to other components, such connections and couplingsmay be realized by a direct connection between components, or by aconnection through other components and devices.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent exemplaryfunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical system of the present invention.

A system may include a host server or other computing systems includinga processor for processing digital data, a memory coupled to saidprocessor for storing digital data, an input digitizer coupled to theprocessor for inputting digital data, an application program stored insaid memory and accessible by said processor for directing processing ofdigital data by said processor, a display coupled to the processor andmemory for displaying information derived from digital data processed bysaid processor, and a plurality of databases, said databases includingclient data, merchant data, financial institution data and/or like datathat could be used in association with the present invention. As thoseskilled in the art will appreciate, a user's computer will typicallyinclude an operating system (e.g., Windows NT, 95/98/2000, Linux,Solaris, etc.) as well as various conventional support software anddrivers typically associated with computers. A user's computer may be ina home or business environment with access to a network. In oneexemplary embodiment, access is through the Internet through acommercially available web-browser software package. In anotherexemplary embodiment, access to the system is through a customer servicerepresentative, with a user in contact with the customer servicerepresentative telephonically. The customer service representativeaccesses the system through a variety of different manners, includingthrough the Internet and through a restricted-access Intranet.

The term “database” may refer to any type of data organizing mechanism,such as relational databases, hierarchical databases, object-orienteddatabases, spreadsheets, and/or the like. Common database products thatmay be used to implement the databases include DB2 by IBM (White Plains,N.Y.), any of the database products available from Oracle Corporation(Redwood Shores, Calif.), Microsoft Access, Microsoft Excel, or SQLServer by Microsoft Corporation (Redmond, Wash.), or any other databaseproduct. Database may be organized in any suitable manner, including asdata tables or lookup tables. Association of certain data may beaccomplished through any data association technique known and practicedin the art. For example, the association may be accomplished eithermanually or automatically. Automatic association techniques may include,for example, a database search, a database merge, GREP, AGREP, SQL,and/or the like. The association step may be accomplished by a databasemerge function. A “key field” partitions the database according to thehigh-level class of objects defined by the key field. For example, acertain class may be designated as a key field in both the first datatable and the second data table, and the two data tables may then bemerged on the basis of the class data in the key field. In thisembodiment, the data corresponding to the key field in each of themerged data tables is preferably the same. However, data tables havingsimilar, though not identical, data in the key fields may also be mergedby using AGREP, for example. It should also be understood that a systemof the present invention is not limited to a physical implementation ofa single repository of information. It is also possible to have multiplerepositories of information. The multiple repositories may be linkedtogether in a variety of different manners to create a single logicalrepository of information.

A data set annotation may also be used for certain types of statusinformation as well as various other purposes. For example, the data setannotation may include security information establishing access levels.The access levels may, for example, be configured to permit only certainindividuals, levels of employees, companies, or other entities to accessdata sets, or to permit access to specific data sets based on thetransaction, merchant, issuer, user or the like. Furthermore, thesecurity information may restrict/permit only certain actions such asaccessing, modifying, and/or deleting data sets. In one example, thedata set annotation indicates that only the data set owner or the userare permitted to delete a data set, various identified merchants arepermitted to access the data set for reading, and others are altogetherexcluded from accessing the data set. However, other access restrictionparameters may also be used allowing various entities to access a dataset with various permission levels as appropriate.

The data, including the header or trailer may be received by astand-alone interaction device configured to add, delete, modify, oraugment the data in accordance with the header or trailer. As such, inone preferred embodiment, the header or trailer is not stored on thetransaction device along with the associated issuer-owned data butinstead the appropriate action may be taken by providing to thetransaction instrument user at the stand-alone device, the appropriateoption for the action to be taken. However, the present inventioncontemplates a data storage arrangement wherein the header or trailer,or header or trailer history, of the data is stored on the transactioninstrument in relation to the appropriate data.

One skilled in the art will also appreciate that, for security reasons,any databases, systems, devices, servers or other components of thepresent invention may consist of any combination thereof at a singlelocation or at multiple locations, wherein each database or systemincludes any of various suitable security features, such as firewalls,access codes, encryption, decryption, compression, decompression, and/orthe like.

Communication between the parties to the transaction and the system ofthe present invention is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, transponder communicationsand/or the like. One skilled in the art will also appreciate that, forsecurity reasons, any databases, systems, or components of the presentinvention may consist of any combination of databases or components at asingle location or at multiple locations, wherein each database orsystem includes any of various suitable security features, such asfirewalls, access codes, encryption, de-encryption, compression,decompression, and/or the like.

The computer may provide a suitable website or other Internet-basedgraphical user interface which is accessible by users. In oneembodiment, the Internet Information Server, Microsoft TransactionServer, and Microsoft SQL Server, are used in conjunction with theMicrosoft operating system, Microsoft NT web server software, aMicrosoft SQL database system, and a Microsoft Commerce Server.Additionally, components such as Access or SQL Server, Oracle, Sybase,Informix MySQL, Intervase, etc., may be used to provide an ADO-compliantdatabase management system. The term “webpage” as it is used herein isnot meant to limit the type of documents and applications that might beused to interact with the user. For example, a typical website mightinclude, in addition to standard HTML documents, various forms, Javaapplets, Javascript, active server pages (ASP), common gateway interfacescripts (CGI), extensible markup language (XML), dynamic HTML, cascadingstyle sheets (CSS), helper applications, plug-ins, and the like.

A block diagram illustrating an embodiment of the present invention isillustrated in FIG. 1. A system of the present invention contains, inone embodiment, a registration component (102), an ownership component(104), and an audit component (106). Registration component 102 isconfigured to facilitate registration of new users and establishing arelationship between the user ID and the account or accounts related tothe user ID. Ownership component 104 is configured to facilitatedefining the criteria used to verify the ownership of the account. Auditcomponent 106 is configured to facilitate validating the relationshipsbetween an account and a user ID on a periodic basis.

A user may initiate a registration process using customer registrationcomponent 102. Registration is the process of granting access to variousservices to a user. For example, one user may wish to be able to trackstocks and mutual funds. Another user may wish to perform on-linebanking services, such as transfers of money and payment of bills. Adifferent user may wish to access his credit card account to viewtransactions and pay bills. Other users may wish to perform more thanone of the above tasks, and/or other similar tasks.

Registration component 102 is in communication with ownership component104. When a user requests a registration, ownership component 104 maydetermine if the user is actually the owner of the account he wishes toaccess. Such a process may occur by asking various questions of theuser, which only the actual owner of the account would be able to answer(as discussed in more detail below). Once the user sufficiently provesthat he is the actual owner of the account to ownership component 104,the user may be granted access to the records he desires. Access may begranted based on an identity of the user. An identity may comprise auser ID and password that is issued to the user, and/or biometric data(such as a retina scan, fingerprint, or the like) that is taken of theuser and associated with the user. In such a situation, the appropriatebiometric reader (e.g., fingerprint scanner, retinal scanner, or thelike), may be issued to the user prior to completions of theregistration process.

When a user attempts to access his information, authentication andaccess component 108 may be used to verify the user. To this end, theuser will be prompted to enter his user ID and password, and/or the usermay be asked to supply biometric data, which may be compared to thebiometric data that was supplied at the time of the registration. Theaction services component 110 may communicate with the authenticationand access component 108 and/or the ownership component 104 regarding,for example, actions performed lately and information of record.

In establishing a user ID, a set of criteria may be pre-established tofacilitate associating a user ID to an account. In the context offinancial services, for example, a financial service provider typicallyhas a large set of data related to each account. In an instance where auser wishes to establish a user ID, registration component 102 hasaccess to subsets of that data through ownership component 104, allowingthe establishment of a relationship between a user ID and all accountsowned by the user. For example, if a user wishes to access his bankaccount on-line, then during the registration process, registrationcomponent 102 and ownership component 104 may determine, for example,that the user also owns a brokerage account and a credit account fromthe same provider of the bank account. Thereafter, an appropriate entrymay be made in ownership component 104, noting the relationships betweenthe user ID and the various accounts. Thus, the user ID established byregistration component 102 may be associated with the bank account, thebrokerage account, and the credit account.

Ownership component 104 may be configured to establish rules to helpensure that adequate ownership information is obtained from a userduring authentication. For example, if a user wishes to associate a userID with a brokerage account, ownership component 104 may be configuredto determine criteria (or include a database of predetermined criteriawhich will be required for certain access requests) to verify that theidentity of the person requesting the ID is the owner of the brokerageaccount. The required criteria may be pre-established, determined basedon past access history, determined based on consumer profile data,randomly determined, changed after a certain number of requests and/orthe like. Moreover, a user wishing to associate a user ID to anothertype of account with less need for security (e.g., the ability to checkthe balance of a credit account) may not utilize the same criteria. Forexample, access to a brokerage account may require that a user input aname, social security number, date of birth, and verify variousinformation. But access to a balance checking feature may only require auser to know the name, address, and account number associated with anaccount. Furthermore, access to a securities tracking feature in whichno transfer of funds is available, may require even fewer securityfeatures.

In addition, this hierarchical registration process can be used to builda relationship over time. For example, a user may register with only thedesire to track securities. As time passes, the user decides to registera credit card. Because some of the user's information is already storedby the system in a database, only the additional information needed toaccess the credit card needs to be obtained from the user. As the userdesires more features with higher security, the user is asked morequestions to verify the user's identity, without the need to re-ask theprevious questions.

For a business organization with multiple business lines, ownershipcomponent 104 may be configured to evaluate each business line todetermine the authentication process each business line uses.Thereafter, ownership component 104 may use an algorithm to generate oracquire a set of questions or criteria that can be used by registrationcomponent 102 to verify that the requesting user is the owner of theaccount.

Occasionally, a user may wish to modify personal information associatedwith an account. For example, a user may wish to submit a change ofaddress. In other situations, a user may require the help of a customerservice representative (“CSR”) to access his account. Such a situationmay occur if a user forgets his user ID or password. In such situations,servicing component 112 may be activated and can interact with the SelfServicing component of the ownership component 104.

With respect to FIG. 2, an exemplary process by which a user mayestablish a user ID with a business comprising multiple business linesis illustrated. A user may access a business system and request a userID (step 202). Such a request may activate registration component 102.Ownership component 104 may determine which accounts from the variousbusinesses are to be associated with the user ID. The user may selectthe various business lines he wishes to be associated with the user ID.Such a selection can be done by first displaying the eligible businesslines, then allowing the user to select (via a graphical user interface)which business lines he wishes to associate with the user ID.Thereafter, ownership component 104 may be activated (step 204).Ownership component 104 may be configured to determine the variousschemes used by the selected business lines to authenticate users (step206). The various authentication processes may be joined in arules-based algorithm to generate (or acquire from a pre-existingdatabase) specific questions to be asked of the user attempting toobtain a user ID (step 208). In this way, one or more rules-basedqueries or R queries are generated to be asked of the user. The usersupplies the answers to the questions in order further verify hisidentity as the owner of the account he is trying to access.

The generating and answering of questions may be a dynamic andinteractive process. For example, the user can be asked questions of hisprofile. Subsequent questions may be generated based upon the answer toprevious questions. A certain number of correct (or substantiallycorrect) answers may result in a confirmation of the identity of theuser. An incorrect answer may lead to further questions in an attempt toconfirm the identity of the user. In addition, a question being askedmay require physical possession of an object. For example, for a creditcard account, a user may be asked to supply information located on thecard or even be asked to swipe the magnetic stripe of the card into areader, should a card reader be available. A user may also be asked toactivate or transmit information (e.g., from a smart chip, transponderor PDA) as confirmation of the user's identity.

Furthermore, biometric information may be used in addition to or as analternative or in addition to issuing a user a User ID and passwordcombination to access certain information. Biometric information mayinclude, for example, fingerprints, retina scans, and the like.

As discussed above, the prior art focused on verifying the ownership ofthe underlying account, ignoring the relationship between a particularuser ID/password and an account. The servicing component 112 minimizesor eliminates these problems by verifying both of the above aspects.Servicing component 112 may generate questions based on informationstored in ownership component 104. The questions being generated may bebased on a user's assigned level of access. As discussed above,different types of accounts may require different levels of access. Auser with only access to tracking features may be required to answerfewer questions than a user with access to money transfer capabilities.The questions being asked may be based on who the user is, what the userknows, what the user has, and what the user has done in the past. Forexample, who the user may include information as to the user's identity,such as the user's name, address, social security number, and the like.What the user knows may include information that only the true user orowner of the account would know. Such information may include the user'smother's maiden name or date of birth, the year of high schoolgraduation, name of a favorite pet, and the like. What the user has mayinclude information contained on a credit card, such as the CID or CVV2number, biometric information, and the like. What the user has done mayinclude previous tasks performed by the user. For example, the user maybe asked where a credit card was last used or an estimate of the lasttransaction amount. In response to correct answers to the generatedquestions, servicing component 112 may verify the user and the CSR orthe user may be able to change various information regarding the user'scard or account.

Even though a set of relationships is robustly validated at the time ofthe creation of the relationships, the set of relationships candeteriorate over time, for a number of reasons. For example, accountexpiration, account re-issuance (e.g., due to a stolen credit card),change in marital status (resulting in a no longer valid card that waspreviously issued to a spouse), change in address, and the like. Inorder to maintain an accurate management of identities, it is desirableto periodically monitor the relationships.

With reference now to FIG. 3, audit component 106 may utilize amathematical weighting function (summarized by exemplary process 300) toassign values to specific interactions captured by the system. In oneembodiment, interactions that serve to confirm the identity of the usermay be assigned positive values (step 302). Examples of these types ofinteractions may include the payment of balances, the receipt ofmerchandise, and/or similar transactions where it is unlikely that anunauthorized user performed the transaction. Interactions that serve toundermine the identity of the user may be assigned negative values (step304). Examples of such interactions may include non-payment of bills,requests to receive merchandise at alternate locations, and/or failedattempts to enter a user id/password/biometric information. One or morepositively weighted interactions may suggest that fraud or accountdeterioration is not occurring. Conversely, one or more negativelyweighted interactions may suggest that fraud or account deterioration isoccurring.

In addition to the examples provided above, a variety of othertransactions, interactions and/or usage behaviors may be captured andcompared to a typical usage pattern and/or a prior interaction/usageand/or another pertinent criterion or set of criteria. As describedabove, the result of a comparison may be used to assign a positive ornegative weight to the interaction/transaction/usage/comparison (steps302 and 304). Typical/prior usage may include the tasks performed by theuser, the location of the user when accessing the system electronically(which may be determined, for example, via the IP address or addressesfrom which they typically connect), and/or usage of the underlyingaccount.

Thus, for example, there may be fraud and/or account deterioration if anaccount is being used or accessed from multiple locations (such ascities, states, countries, etc.) Likewise, there may be fraud and/oraccount deterioration where an account is used or accessed from multipleinternet service providers (ISPs), Internet protocol (IP) addresses,browsers, and/or devices (e.g., devices having different media accesscontrol (MAC) addresses, personal computers, cell phones, smart phones,PDAs, kiosks, and the like).

The time during which an account is used or accessed may provide furtherinsight into the likelihood or possibility of fraud/accountdeterioration. For example, an access attempt during the nighttime maypresent a greater likelihood of fraud than an account that is accessedduring the daytime (e.g., morning, afternoon, evening, etc.) Further,consecutive or repeated access attempts may suggest fraud/accountdeterioration, where, for example, a user attempts to gain access to anaccount repeatedly over the course of several seconds, minutes, hours,or even days. Further still, the timing of multiple access attempts maybe coupled to the location of each access attempt and/or the device fromwhich each access attempt was made in order to detect potentiallyfraudulent behavior. For example, a first access attempt from location Amay be compared to a second access attempt from location B, which is,for instance, several hundred or several thousand miles distant fromlocation A. Although the disparity in location may alone suggestfraud/account deterioration, the timing of each access attempt may becompared, and, where for example, the first attempt was made onlyseconds or minutes prior to the second attempt, fraud/accountdeterioration is virtually certain.

Further still, the order in which one or more accounts are accessed,and/or the order in which a user performs operations (e.g.,transactions, interactions) on or within an account may be useful indetermining whether fraudulent activity/account deterioration areoccurring. For example, a user who first attempts to change or changesaccount information (e.g., a user id, a password, a name, an address, atelephone number, etc.) and next attempts to withdraw funds or close thesame or a related account may be engaged in fraud. Likewise, a user whomodifies or attempts to modify an account/information associatedtherewith and next applies for a new or increased line of credit and/orexpends substantial existing credit may be engaged in potentiallyfraudulent or suspicious activity. Thus, the order in which an accountor accounts are accessed/modified/utilized may be associated with apositive or negative weighting.

Fraud and/or account deterioration may be further detected by comparinga transaction to a pattern of transactions, where the transaction andpattern of transactions may be associated with one or more accounts(e.g., multiple lines of credit/bank accounts or a single line ofcredit/bank account). For example, a purchase of an airline ticket withan account which a user typically makes small purchases (e.g.,groceries, movie tickets, etc.) may indicate fraudulentactivity/deterioration of an account. Likewise, a user who utilizes oneor more accounts to purchase from several categories of items (e.g.,groceries, electronics, and airline tickets) may be at risk of fraudand/or account deterioration where, for example, one or more of thoseaccounts are used to make a purchase that is uncharacteristic of thecustomary categories (e.g., a limousine rental). In these and similarcircumstances, the comparison may be associated with a negativeweighting. A positive weighting, as the reader may well imagine, may beassigned to a comparison that is characteristic of a customary categoryof purchasing/transaction activity and/or an otherwise characteristic ornon-anomalous purchase or transaction.

Similarly, a pattern of regular spending amounts and/or a pattern ofinquiries, withdrawals, and/or deposits may reveal fraudulentactivity/account deterioration. For instance, a user who uses an accountor accounts to make a purchase for an amount that is uncharacteristic ofa pattern of amounts may be at risk of fraud/account deterioration. Thatis, for example, a user who typically uses an account to make purchasesof less than $500 or only on weekends may be at risk where a purchase ina greater amount (e.g., $1000) or on a non-weekend is made using theaccount. Moreover, spending patterns may be associated with groups ofitems/products. For example, a user may have a first spending patternfor his groceries (i.e., every Sunday and in an amount less than $100from Trader Joe's) and a second spending pattern for air travel (e.g.,typically over Christmas and for several weeks during the summer). Auser may be further associated with patterns of inquiry (e.g., a userlogs in every Saturday morning to check his account balance), patternsof withdrawal (e.g., a user withdraws funds every Friday in an amountthat rarely exceeds $100), and/or patterns of deposit (e.g., a user'semployer directly deposits his paycheck on a regular basis). Thesepatterns may be compared to individual activity (e.g., spending,inquiry, withdrawal, and/or deposit), and a positive or negativeweighting may be assigned to the comparison as described above. That is,a negative weighting may be assigned to a comparison that revealsactivity uncharacteristic of a pattern, and a positive weighting may beassigned to a comparison that reveals activity characteristic of apattern.

The data described above may be updated at regular intervals. Forexample, each time the user accesses the system, a similarity score maybe computed that indicates the similarity of the transaction to previoustransactions, and/or the location and/or device information associatedwith the access request may be logged. Thus, each usage or interactionestablishes or adds to a usage history for a user, and data entries in ausage history may be compared to determine a likelihood of fraud and/oraccount deterioration (step 306).

Accordingly, a negative weight (and a positive weight, in the reversescenario) may be assigned to a transaction based on any or all of theforegoing criteria (steps 302 and 304). To summarize, based on thenegative and positive weights, a transaction may be flagged aspotentially fraudulent or associated with potential accountdeterioration. (step 306).

In addition to the foregoing, certain interactions may be weighted inaggregate form. In other words, some combinations of events may haverelationships with each other. For example, a series ofidentity-undermining events may have an aggregate negative weightingthat exceeds the individual negative weightings described above, or acumulative negative weighting that exceeds the aggregation or sum of theindividual negative weightings in the series of identity-underminingevents. Likewise, a series of identity-confirming events may have anaggregate positive weighting that exceeds the individual positiveweightings described above, or a cumulative positive weighting thatexceeds the aggregation or sum of the individual positive weightings inthe series of identity-confirming events.

Positive and negative scores (both in the aggregate an individually) maybe changed into a probability score using a variety of differentalgorithms. For example, a certain number of positive scores combinedwith a number of negative scores results in a probability score of 95%,indicating a 95% likelihood that the user is who he says he is. Theprobability score can be combined with the hierarchical scheme ofregistrations to require different probability scores to accessdifferent systems. For example, a probability of 80% may be sufficientto allow access to a securities tracking system, but a probability of99.99% may be required to allow trading of securities.

The system may increase security by asking specific questions that onlya user would know the answer to, prior to allowing the user to performcertain transactions. For example, additional questions may be askedwhen a user attempts to transfer funds, obtain a cash advance, or othersuch transactions that have been determined to require more security toperform. Such questions are more specific and would only be known to theuser or cardholder, and not to those who, for example, steal a creditcard or attempt to fraudulently or accidentally gain access to anaccount that is not their own. Such a question may include queriesregarding previous purchases, questions regarding associated accounts,and the like, in addition to questions regarding the account holder,such as address, social security number, date of birth, somewhere youare, something you've done, and the like. The questions asked can bedetermined algorithmically using various methods. Correct answers tosuch questions not only allow the user to perform the requested tasks,but also increase the above-described certainty measure of the user.

Such questions may be asked telephonically. In such a case, it may bedesirable to avoid having a human CSR who may possibly be able to stealsuch information. In such a situation, a voice recognition unit (“VRU”),or interactive voice response (“IVR”) may be used to obtain the answersfrom the users and translate the answers into a computer-readable form,without the need for additional human assistance. In addition, when aCSR is involved in a servicing process, each of the CSR's activities maybe tracked. Such a tracking system can be integrated into a frauddetection system. Such a process can be used to determine if a CSR isinvolved in identity-theft.

The audit module 106 may include a periodic self-audit of information.To ensure that proper data exists for each user, an audit can beconducted periodically. Such an audit may consist of querying a user asto the user's contact information. The user can confirm or update theinformation. To ensure that the user is who he says he is, the user mayalso be required to answer questions, such as those described in moredetail above. Such a task ensures that accurate information regardingeach user is stored. For example, if a user changes residence, such afact can be determined by the periodic audit. In one embodiment, theperiodic audit may occur annually. Moreover, where an identity isassociated with one or more negatively weighted transactions, the auditmodule 106 may verify the relationship of the identity with the account.

It can thus be seen that the problems of the prior art can be eliminatedby an embodiment of the present invention. For example, it would not bepossible for the owner of user ID JSMITH2 to obtain access to the userID JSMITH1, as the servicing component in conjunction with the ownershipcomponent would determine that, although he is the owner of an account,he is not the owner of the account associated with the JSMITH1 user ID.

The present invention is described herein with reference to blockdiagrams, flowchart illustrations of methods, systems, and computerprogram products according to various aspects of the invention. It willbe understood that each functional block of the block diagrams and theflowchart illustrations, and combinations of functional blocks in blockdiagrams and flowchart illustrations, respectively, may be implementedby computer program instructions. These computer program instructionsmay be loaded on a general purpose computer, special purpose computer,or other programmable data processing apparatus to produce a machine,such that the instructions which execute on the computer or otherprogrammable data processing apparatus create means for implementing thefunctions specified in the flowchart block or blocks.

It will be appreciated, that many applications of the present inventioncould be formulated. One skilled in the art will appreciate that thenetwork may include any system for exchanging data or transactingbusiness, such as the Internet, an intranet, an extranet, WAN, LAN,satellite communications, and/or the like. It is noted that the networkmay be implemented as other types of networks, such as an interactivetelevision (ITV) network. The users may interact with the system via anyinput device such as a keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot®), cellular phone and/orthe like. Similarly, the invention could be used in conjunction with anytype of personal computer, network computer, workstation, minicomputer,mainframe, or the like running any operating system such as any versionof Windows, Windows NT, Windows 2000, Windows 98, Windows 95, Mac OS,OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, although theinvention is frequently described herein as being implemented withTCP/IP communications protocols, it will be readily understood that theinvention could also be implemented using IPX, Appletalk, IP-6, NetBIOS,OSI or any number of existing or future protocols. Moreover, the systemcontemplates the use, sale or distribution of any goods, services orinformation over any network having similar functionality describedherein.

The computing units may be connected with each other via a datacommunication network. The network may be a public network and assumedto be insecure and open to eavesdroppers. In the illustratedimplementation, the network may be embodied as the Internet. In thiscontext, the computers may or may not be connected to the Internet atall times. For instance, the customer computer may employ a modem tooccasionally connect to the Internet, whereas the bank-computing centermight maintain a permanent connection to the Internet. Specificinformation related to the protocols, standards, and applicationsoftware utilized in connection with the Internet may not be discussedherein. For further information regarding such details, see, forexample, DILIP NAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2COMPLETE, various authors, (Sybex 1999); DEBORAH RAY AND ERIC RAY,MASTERING HTML 4.0 (1997). LOSHIN, TCP/IP CLEARLY EXPLAINED (1997). Allof these texts are hereby incorporated by reference.

These computer program instructions may also be stored in acomputer-readable memory such as a computer readable storage medium thatcan direct a computer or other programmable data processing apparatus tofunction in a particular manner, such that the instructions stored inthe computer-readable memory produce an article of manufacture includinginstruction means which implement the function specified in theflowchart block or blocks. The computer program instructions may also beloaded on a computer or other programmable data processing apparatus tocause a series of operational steps to be performed on the computer orother programmable apparatus to produce a computer-implemented processsuch that the instructions which execute on the computer or otherprogrammable apparatus provide steps for implementing the functionsspecified in the flowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, it will be appreciated thatvarious modifications and changes can be made without departing from thescope of the present invention. The specification and figures are to beregarded in an illustrative manner, rather than a restrictive one, andall such modifications are intended to be included within the scope ofpresent invention.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. No elementdescribed herein is required for the practice of the invention unlessexpressly described as “essential” or “critical”.

1. A method comprising: comparing, by a computer-based system foridentity management, a first transaction to a second transaction;assigning, by the computer-based system, one of a positive weight and anegative weight to the comparison based upon the order in which thefirst transaction and the second transaction occur; and determining, bythe computer-based system, a likelihood that an identity owns an accountassociated with the first transaction and the second transaction basedupon the positive or negative weight.
 2. The method of claim 1, furthercomprising aggregating, by the computer-based system, a plurality ofpositive weights and a plurality of negative weights to determine ausage history of a user.
 3. The method of claim 1, wherein thedetermining a likelihood further comprises converting, by thecomputer-based system, the positive weight and the negative weight to aprobability score.
 4. The method of claim 1, further comprisingassigning, by the computer-based system, a negative weight to thecomparison in response to a first transaction comprising a request tomodify account information associated with the account and a secondtransaction comprising a request to close the account.
 5. The method ofclaim 1, further comprising allowing, by the computer-based system, theidentity to access a first account in a hierarchy of accounts based upona probability score that is lower than a probability score required toaccess a second account in the hierarchy of accounts.
 6. The method ofclaim 1, further comprising allowing, by the computer-based system, theidentity to access the account based upon a probability score.
 7. Themethod of claim 1, further comprising facilitating, by thecomputer-based system, periodic confirmation of at least one of:identity information from a user and ownership information from theuser.
 8. An article of manufacture including a non-transitory, tangiblecomputer readable medium having instructions stored thereon that, inresponse to execution by a computer-based system for identitymanagement, cause the computer-based system to perform operationscomprising: comparing, by the computer-based system, a first transactionto a second transaction; assigning, by the computer-based system, one ofa positive weight and a negative weight to the comparison based upon theorder in which the first transaction and the second transaction occur;and determining, by the computer-based system, a likelihood that anidentity owns an account associated with the first transaction and thesecond transaction based upon the positive or negative weight.
 9. Thearticle of claim 8, further comprising aggregating, by thecomputer-based system, a plurality of positive weights and a pluralityof negative weights to determine a usage history of a user.
 10. Thearticle of claim 8, wherein the determining a likelihood furthercomprises converting, by the computer-based system, the positive weightand the negative weight to a probability score.
 11. The article of claim8, further comprising assigning, by the computer-based system, anegative weight to the comparison in response to a first transactioncomprising a request to modify account information associated with theaccount and a second transaction comprising a request to close theaccount.
 12. The article of claim 8, further comprising allowing, by thecomputer-based system, the identity to access a first account in ahierarchy of accounts based upon a probability score that is lower thana probability score required to access a second account in the hierarchyof accounts.
 13. The article of claim 8, allowing, by the computer-basedsystem, the identity to access the account based upon a probabilityscore.
 14. The article of claim 8, further comprising facilitating, bythe computer-based system, periodic confirmation of at least one of:identity information from a user and ownership information from theuser.
 15. A system comprising: a processor for identity management, atangible, non-transitory memory configured to communicate with theprocessor, the tangible, non-transitory memory having instructionsstored thereon that, in response to execution by the processor, causethe processor to perform operations comprising: comparing, by theprocessor, a first transaction to a second transaction; assigning, bythe processor, one of a positive weight and a negative weight to thecomparison based upon the order in which the first transaction and thesecond transaction occur; and determining, by the processor, alikelihood that an identity owns an account associated with the firsttransaction and the second transaction based upon the positive ornegative weight.
 16. The system of claim 15, further comprisingaggregating, by the processor, a plurality of positive weights and aplurality of negative weights to determine a usage history of a user.17. The system of claim 15, wherein the determining a likelihood furthercomprises converting, by the processor, the positive weight and thenegative weight to a probability score.
 18. The system of claim 15,further comprising assigning, by the processor, a negative weight to thecomparison in response to a first transaction comprising a request tomodify account information associated with the account and a secondtransaction comprising a request to close the account.
 19. The system ofclaim 15, further comprising allowing, by the processor, the identity toaccess a first account in a hierarchy of accounts based upon aprobability score that is lower than a probability score required toaccess a second account in the hierarchy of accounts.
 20. The system ofclaim 15, further comprising allowing, by the processor, the identity toaccess the account based upon a probability score.